1. Field of the Invention
This invention pertains generally to methods of communication between communication devices and, more particularly, to a method and apparatus for providing push-to-talk (PTT) communication services in a communication system such as, for example, a cellular telephone system.
2. Background Information
A wireless push-to-talk (PTT) communication system such as, for example, a push-to-talk over cellular (PoC) system, allows a group of individuals, each having a wireless communication device, such as a cellular telephone, to communicate with other members of the group. Early PTT systems typically relied on a single frequency, or a dedicated broadcast channel, over which communications were received by the wireless communication devices. In most early systems, only one member could transmit information to the other members at a time. However, all members could listen to the dedicated channel, in order to receive communications from the member who is transmitting. A member desiring to transmit to other members of the system typically would send an access request by depressing a PTT button on the member's wireless communication device, which allows sole access to the dedicated channel.
Internet telephony encompasses a number of technologies for the transport of voice traffic over Internet Protocol (IP) networks. Examples of IP signaling protocols include the International Telecommunications Union-Telecommunications Standardization Sector (ITU-T) H.323 and the Internet Engineering Task Force (IETF) specified Session Initiation Protocol (SIP), RFC 3261, which is used as the signaling protocol for the 3GPP IP multimedia subsystem (IMS). Wireless communication devices find, join, leave and learn about various groups of people requiring communications with each other (e.g., nets) using, for example, SIP, which is a well-known signaling protocol used in the telecommunications industry. SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more users. These sessions include, for example, Internet telephone calls, multimedia distribution and multimedia conferences.
One SIP function is registration between a SIP uniform resource identifier (i.e., a sequence of characters employed for addressing resources and users for transmission in a network protocol and for representation of human language communication, e.g., a SIP:URI) and one or more contact addresses (e.g., a device address, such as an IP address). Registration permits a wireless communication device to communicate with and be recognized by other wireless communication devices. SIP, through its registration function, permits a user agent to create, modify and delete registrations. Basic registration includes the address-of-record that the registration refers to, identification of registration and state of registration. The registration states may be initialized, activated and terminated. As long as there is at least one contact bound to the address-of-record, a SIP state machine remains in its active state. When the last contact expires or is removed, the registration transitions to the terminated state. The registration state is normally stored in a proxy/registrar or in a separate database. When the SIP wireless communication device is continuously on, it must be continuously registered to the SIP/IP network if it is to use the services of the 3GPP IMS SIP based network. Registrations may be used by policy administrators to terminate or shorten a registration, and to request that the wireless communication device re-register, in order that it can be re-authenticated.
A SIP PTT wireless communication device or PTT terminal may support different operating answer modes including an Auto-Answer mode and a Manual-Answer mode. For example, when a PTT terminal is in the Auto-Answer mode, then when another user in the corresponding net/group presses a PTT button on their PTT terminal and speaks into that PTT terminal, the other user(s) with PTT terminals set to the Auto-Answer mode hear that spoken voice from their PTT terminal(s). Alternatively, when a PTT terminal is in the Manual-Answer mode, the other user(s) of that PTT terminal must manually answer (e.g., there is first a “ring” at the PTT terminal(s)) before hearing that spoken voice. A further enhancement to this basic concept is the use of network stored Authorization Accept Lists with per user authorization of the operating answer mode for PTT sessions from each user (some users may have only Manual-Answer privilege, while other users may have Auto-Answer privilege). When used with per user authorization, the handling for the PTT session is determined by a combination of the calling user's Authorization privilege on the Accept List and the operating answer mode set by the terminal. There are, therefore, two possible cases for Auto-Answer: (1) Auto-Answer mode where only those users that have Auto-Answer privilege on the Accept List cause the terminal to answer automatically; and (2) Always-Auto-Answer mode where all users on the Accept List, regardless of privilege, cause the terminal to answer automatically. The terminal may support one or two or all three of these operating modes. The operating answer mode may be selected by the user at the PTT terminal by employing, for example, a physical switch or button, one or more settings of an enabled profile, or by some other suitable mechanism. Since the operating answer mode changes the network signaling scenario of the SIP/IP PTT network server that controls the setup of SIP PTT sessions, this mode of the SIP PTT terminal needs to be communicated to the network server.
FIG. 1 shows a SIP/IP core network 1 including a PTT server 2, a presence server 3 and a plurality of SIP PTT terminals 4,5,6. Although wireless SIP PTT terminals 4,5,6 are shown, wire line (e.g., land line-based or local area network (LAN) based) PTT terminals (not shown) may be employed.
A PTT terminal, such as 4, may typically include an optional antenna 8, an optional display 9, a plurality of keys 10, a mouthpiece or microphone 11, an earpiece, earphone, headset or loudspeaker 12, and a PTT switch 13. Alternatively, one of the existing keys 10 or selection of a displayed menu option may function as a PTT switch when in a PTT mode of communication instead of using the dedicated PTT switch 13.
In the SIP/IP core network 1, group creation is possibly based on HTTP and XCAP, and signaling control is based upon SIP. Voice traffic is carried out through a suitable Internet protocol, such as Real-time Transport Protocol (RTP), which is designed to provide end-to-end network transport functions for applications transmitting real-time data, such as voice and video. Both SIP and RTP sit at the top of an IP related stack including UDP and IP layers. A plurality of suitable PoC applications form the top layer of a PoC protocol stack, which includes that IP related stack. A suitable mobile channel, such as 3GPP R99 upgraded GPRS or E-GPRS or W-CDMA/UMTS, or CDMA 2000 1X or its variants, WLAN access or other 3G radio access technologies, provides the access network, which supports header compression and streaming traffic class Quality of Service (QoS).
A Header is a component of a SIP message, such as 14, that conveys information about the message. It is structured as a sequence of header fields.
A header field is a component of a SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row.
A Header Field Value is a single value. A header field consists of zero or more header field values.
A Message is data sent between SIP elements, such as 2-7, as part of the SIP protocol. SIP messages 14,15,16 are either requests or responses.
A Request, such as 14,15, is a SIP message sent from a client to a server, for the purpose of invoking a particular operation.
A Response, such as 16, is a SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server.
A Server, such as 2,3,7, is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers and registrars.
The network-based PTT server 2 receives invitations for group communication from one user. In response, the server 2 invites all the other members of the group to the communication, controls the “floor” (e.g., the right to speak), bridges the communication between all the members of the net/group, and needs to know the current answer mode of the SIP PTT terminals 4,5,6 for proper signaling conditions, and communication media handling.
The network-based presence server 3 stores Presence Information published by the individual SIP PTT terminals 4,5,6, and also possibly other network based sources (e.g., servers, such as 2,7) and delivers Notifications of Presence Information to authorized watchers who subscribe to the Presence Information using their terminals.
The SIP registrar 7 is a server that accepts SIP Register requests and places the information it receives in those requests into the location service database for the domain it handles.
There is one known prior proposal for dealing with an answering mode setting in a PoC SIP/IP core network. In addition to accept control lists, the PoC system has an auto-answer mode flag, which can be set on a user and/or a group basis. The auto-answer mode flag is stored in a Group Management Server (GLMS) (not shown) in a Group Management database that is accessed by the PoC PTT server 2. The user has the ability to configure the corresponding PTT terminal, such as 4, to either automatically accept the incoming session request or to be prompted before accepting the request. In the simplest case, if the user sets auto-answer mode on, then the auto-answer mode is applied to the incoming PoC sessions. Otherwise, if the auto-answer mode is off, then the manual-answer mode is applied.
It is believed that this prior proposal is inappropriate because: (1) modifying data in the GLMS requires use of an HTTP database modification protocol; (2) the change of answer mode may be made, for example, by a switch or by selection of a profile, which does not map well to a database manipulation (e.g., this requires a high degree of complexity in the terminal to synchronize with and manipulate a database in response to a simple stimulus like a switch; also, the database manipulation protocol may not be supported by all terminals as the individual users may not have the authorization to manipulate their own group and authorization lists, since their company controls this; further, a simple telephone keypad is not ideal for entering and creating a large list of text based information); and (3) depending upon the user, the answer mode may change many times a day (e.g., it is relatively very dynamic), while data (e.g., address book entries; preferences for those users) stored in the GLMS hardly ever is changed (e.g., it is relatively almost static). The IETF has defined this division of relatively static and relatively dynamic data as “Hard State” and “Soft State,” respectively. Different protocol mechanisms are appropriate to manipulate Hard State and Soft State data. The answer mode is considered as Soft State, the manipulation of groups and lists in a database is considered Hard State.
Hence, it is believed that it is more efficient than employing an HTTP mechanism to simply report the answer mode state change/event to the network. Accordingly, there is room for improvement in wireless PTT systems and methods.